The basic functionality of a computer is dictated by the type of operating system it uses. Various operating systems exist in the market place, including Solaris™ from Sun Microsystems Inc., Palo Alto, Calif. (Sun Microsystems), MacOS® from Apple Computer, Inc., Cupertino, Calif., Windows® 95/98 and Windows NT®, from Microsoft Corporation, Redmond, Wash., and Linux. The different types of operating systems will be referred to herein as “platforms”. Prior to the popularity of the Internet, software developers wrote programs specifically designed for individual platforms. Thus, a program written for one platform could not be run on another. However, the advent of the Internet made cross-platform compatibility a necessity.
Prior art FIG. 1 illustrates a conceptual arrangement wherein a first computer (3) running the Solaris™ platform and a second computer (5) running the Windows® 98 platform are connected to a server (9) via the internet (7). A resource provider using the server (9) might be any type of business, governmental, or educational institution. The resource provider has a need to be able to provide its resources to both the user of the Solaris™ platform and the user of the Windows® 98 platform, but does not have the luxury of being able to custom design its content for the individual platforms.
The Java™ programming language was developed by Sun Microsystems to address this problem. The Java™ programming language was designed to be simple for the programmer to use, yet able to run securely over a network and work on a wide range of platforms.
Referring to FIG. 2, in order to create a Java™ application, the developer first writes the application in human-readable Java™ source code. As used herein, the term “application” refers to Java™ 2 Standard Edition (J2SE™) applications, Java™ 2 Micro Edition (J2ME™), and Java™ “applets” which are essentially small applications usually embedded in a web page. In the example shown, the application “Program” (11) is created as a human-readable text file. The text file contains Java™ language commands, e.g. “import java.awt.frame.” The name of this text file is given the required five-character extension “.java”.
The Java™ compiler (“javac”, “fastjavac”, “jvc”, et. al.) (13) is used to compile the source code into a platform independent bytecode (15). Compilation of J2ME™ applications is slightly different than for J2SE™. The J2ME™ compilation process adds a pre-verification step after the bytecode (15) is generated. This final step produces a pre-verified bytecode. Using either method of compilation, the resulting binary file (15) will automatically receive the same file name as the source text file with “.class” extension or the same name of the source file plus a special character “$” plus the name of an inner class with the extension “.class.”
The Java™ runtime environment incorporates a virtual machine (16) to verify whether a given bytecode (15) has the proper format (verification process) and convert the “.class” byte codes into actual machine executions (17). The machine executions (like drawing windows, buttons, and user prompt fields) will occur in accordance to the application developer's code instructions. Because Sun Microsystems specifically designed the virtual machine (16) to run on different platforms, a single set of “.class” byte codes will execute on any platform where a virtual machine (16) has been installed. An Internet browser such as Netscape® and Microsoft® Internet Explorer that incorporates a virtual machine (16) is called a “java-enabled” browser. A discussion of the Java™ language itself is beyond the scope of this document. However, complete information regarding the Java™ programming language and the Java™ platform are available from Sun Microsystems in print.
The cross-platform architecture of the Java™ programming language is illustrated in FIG. 3, which shows how the Java™ language enables cross-platform applications over the Internet. In the figure, the computer (3) running the Solaris™ platform and the computer (5) running the Windows® 98 platform are both provided with the virtual machine (16). The resource provider creates a Java™ application using the Java™ software development kit (“SDK”) (23) and makes the compiled Java™ byte codes available on the server (9), which in this example is running on a Windows NT® platform. Through standard Internet protocols, both the computer (3) and the computer (5) may obtain a copy of the same byte code and, despite the difference in platforms, execute the byte code through their respective virtual machine (16).
As the popularity of the Internet has increased, users have become accustomed to many different types of interfaces. Thus, aesthetic conformity has become less of an issue. At the same time, speed, functionality, and versatility have become increasingly important. Therefore, the J2SE™ SDK includes a new “package” for the developer called “swing” that is essentially library of “lightweight components”. This new package is simply one library that is possible; other libraries may be created and in fact are available from third parties. Swing provides the developer with the option and flexibility to use lightweight. A detailed discussion of the Swing package is beyond the scope of this document. Complete documentation is available from Sun Microsystems both in print and at the web site java.sun.com.
Forte for Java™ products derived from NetBeans™ Open Source Project, are visual programming environments written entirely in Java™ and Swing. These products are commonly regarded as Integrated Development Environment (IDE). This IDE is easily customizable and extensible, as well as platform independent. As is illustrated in FIG. 5, Forte™ for Java™ includes a powerful Form Editor (92), integrated full-featured text editor (94), debugger (98), compiler (100), etc. Forte™ for Java™ is also completely modular and is built around a set of Open Application Programming Interface (API's) which allow the IDE to be easily extensible. This means that the IDE functionality for editing, debugging, GUI generation, etc. is represented in modules that can be downloaded and updated dynamically as is illustrated in FIG. 5. Instead of waiting months for a completely new release, as soon as new versions (104) or new modules (106) are available, users can update that individual version or module via the Update Center (102) or from other vendors.
With an increase in popularity of mobile, wireless-connected devices (like cellular phones, personal digital assistants, point of sale terminals, two-way pagers or any other device constrained in processing power, memory and graphical capability), the release of J2ME™ technology (50) has emerged. J2ME™ is the edition of Java™ 2 platform that targets consumer electronics and embedded devices. J2ME™ technology (50) allows the use of applications that are on these devices targeted at satisfying consumer market demand for wireless access to at-your-fingertips information, service, and entertainment (e.g., sport scores, financial information, e-commerce, games, interpersonal communication, etc.). This J2ME™ technology provides a standard platform for small, resource-limited, wireless-connected mobile information devices.
In addition to being wireless-connected, these mobile information devices have small displays, low bandwidth, high latency network connections, limited input devices, limited local storage, battery life and processor power. These devices may be roughly divided into two categories: devices that are mostly mobile, and devices that typically remain fixed. The hardware and network resources available to mobile devices tend to be more limited than in the case of devices with an ample supply of wall-power. Conversely, devices with easy access to power and wired network connections can take advantage of the wires to provide more power and sophistication to the user. Recognizing this distinction, the J2ME™ technology (50) consists of the virtual machine (16) and set of APIs suitable for providing tailored runtime environments for consumer and embedded electronics.
J2ME™ technology (50) as depicted in FIG. 6 has two primary kinds of components—a configuration (38) and a profile (54). The configuration (38) is the combination of a virtual machine (any virtual machine that is at least as capable as a Sun Microsystems K virtual machine (KVM)) and “core” APIs (52) that represent an underlying development platform for a broad class of devices. Configurations (38) are nestable, so that any software able to execute on a less capable configuration is able to execute on a more capable one. At present, two accepted configurations (38) are a Connected Device Configuration (CDC) and a J2ME™ Connected Limited Device Configuration (CLDC) (39). The CDC is a more robust configuration that allows any software to be able to execute on larger, fixed hardware. The design center for smaller handheld devices is addressed by the CLDC (39). The CLDC (39) specification outlines the most basic set of libraries and virtual machine features (16) that must be present in each implementation of a J2ME™ environment on highly constrained devices. To form a complete environment for any given class of device, manufacturers add additional libraries, that address API areas not dealt with in the low-level CLDC (39), such as user interface and device-specific networking.
The heart of the CLDC (39) and J2ME™ technology (50) in mobile devices is KVM. The KVM is a virtual machine designed from the ground up with the constraints of inexpensive mobile devices in mind. It is highly optimized for very resource-constrained consumer devices. Named to reflect that its size is measured in the tens of kilobytes, the KVM is suitable for devices with 16/32-bit RISC/CISC microprocessors/controllers, and with as little as 160 K of total memory available, of which 128 K is for the storage of the KVM and libraries themselves. Like all virtual machines (16), the KVM provides the foundation for the download and execution of dynamic content and services.
Like a standard virtual machine (16), a KVM supporting CLDC (39) must be able to reject invalid classfiles. However, since the static and dynamic memory footprint of the standard Java™ classfile verifier is excessive for a typical CLDC (39) target device, a more compact and efficient verification solution has been created. The implementation of the new verifier in the KVM requires about ten kilobytes binary code and less than 100 bytes of dynamic RAM at runtime for typical class files. The verifier performs only a linear scan of the bytecode (15), without the need of a costly iterative dataflow algorithm. The new verifier requires Java classfiles to contain a special attribute. The new verifier includes a pre-verification tool that inserts this attribute into normal class files. A transformed class file is still a valid J2SE™ class file, with additional attributes. These attributes are automatically ignored by the conventional classfile verifier, so the solution is fully upward compatible with the J2SE™ virtual machine (16).
The profile (54) is a set of original equipment manufacturer (OEM) specific APIs (34) built on top of and utilizing an underlying configuration (38), necessary to provide a complete runtime environment for a specific kind of device. The profile (54) must be complete in the sense that an application written to the specification can execute in the specified Java™ technology environment without the addition of other Java™ classes. The profile (54) can be thought of as selecting classes from APIs to form a complete environment. The profile (54) is designed and integrated to meet the needs of specific industry segments. At present, two J2ME™ wireless profiles exist: 1) Mobile Information Device Profile (MIDP) (30) and 2) DoJa, which is a proprietary profile developed by NTT DoCoMo similar to MIDP (30).
The MIDP (30) is a set of Java™ APIs which, together with the CLDC (39), provides a complete J2ME™ application runtime environment targeted at mobile information devices, such as cellular phones and two-way pagers. A diagram showing the relationship between MIDP (30), CLDC (39), OEM specific APIs (34) and MIDP applications (36)/OEM applications (34) running on different platforms (40) is shown in FIG. 7. The MIDP specification addresses issues such as user interface, persistence storage, networking, and application model. The MIDP specification also provides a standard runtime environment that allows new applications and services to be dynamically deployed on end user devices.
Any J2ME™ wireless application may be in the form of an MIDP applications (36) or an OEM application (34). However, as is shown in FIG. 8, the applications are not totally different. A J2ME™ wireless application consists of two files, namely a jar file (58) and an application descriptor (60). The jar file (58) contains the MIDP application (36) itself. The application descriptor (60) contains information such as the name of the application, location of the jar file, and main class. The IDE uses the same user interface for both types of the applications, but the format of the file that is used for storing and checking of values depends on type of the application.